home *** CD-ROM | disk | FTP | other *** search
/ Usenet 1993 July / InfoMagic USENET CD-ROM July 1993.ISO / answers / lisp-faq / part5 < prev    next >
Encoding:
Text File  |  1993-06-13  |  16.2 KB  |  331 lines

  1. Newsgroups: comp.lang.lisp,comp.lang.clos,news.answers,comp.answers
  2. Path: senator-bedfellow.mit.edu!enterpoop.mit.edu!usc!math.ohio-state.edu!magnus.acs.ohio-state.edu!cis.ohio-state.edu!news.sei.cmu.edu!bb3.andrew.cmu.edu!crabapple.srv.cs.cmu.edu!mkant
  3. From: mkant+@cs.cmu.edu (Mark Kantrowitz)
  4. Subject: FAQ: Object-oriented Programming in Lisp 5/7 [Monthly posting]
  5. Message-ID: <lisp-faq-5.text_739958521@cs.cmu.edu>
  6. Followup-To: poster
  7. Summary: Questions about CLOS, PCL and object-oriented programming in Lisp
  8. Sender: news@cs.cmu.edu (Usenet News System)
  9. Supersedes: <lisp-faq-5.text_737280285@cs.cmu.edu>
  10. Nntp-Posting-Host: a.gp.cs.cmu.edu
  11. Reply-To: lisp-faq@think.com
  12. Organization: School of Computer Science, Carnegie Mellon
  13. Date: Sun, 13 Jun 1993 08:02:11 GMT
  14. Approved: news-answers-request@MIT.Edu
  15. Expires: Sun, 25 Jul 1993 08:02:01 GMT
  16. Lines: 312
  17. Xref: senator-bedfellow.mit.edu comp.lang.lisp:10306 comp.lang.clos:1838 news.answers:9336 comp.answers:971
  18.  
  19. Archive-name: lisp-faq/part5
  20. Last-Modified: Mon Jun  7 17:08:08 1993 by Mark Kantrowitz
  21. Version: 1.34
  22.  
  23. ;;; ****************************************************************
  24. ;;; Answers to Frequently Asked Questions about Lisp ***************
  25. ;;; ****************************************************************
  26. ;;; Written by Mark Kantrowitz and Barry Margolin
  27. ;;; lisp-faq-5.text -- 15954 bytes
  28.  
  29. This post contains Part 5 of the Lisp FAQ. It is cross-posted to the
  30. newsgroup comp.lang.clos because it contains material of interest to
  31. people concerned with CLOS, PCL and object-oriented programming in
  32. Lisp. The other parts of the Lisp FAQ are posted only to the
  33. newsgroups comp.lang.lisp and news.answers.
  34.  
  35. If you think of questions that are appropriate for this FAQ, or would
  36. like to improve an answer, please send email to us at lisp-faq@think.com.
  37.  
  38. CLOS/PCL Questions (Part 5):
  39.  
  40.   [5-0]   What is CLOS (PCL) and where can I get it?
  41.           How do you pronounce CLOS?
  42.   [5-1]   What documentation is available about object-oriented
  43.           programming in Lisp?  
  44.   [5-2]   How I write a function that can access defstruct slots by
  45.           name?  I would like to write something like 
  46.           (STRUCTURE-SLOT <object> '<slot-name>).   
  47.   [5-3]   How can I list all the CLOS instances in a class?
  48.   [5-4]   How can I store data and CLOS instances (with possibly circular
  49.           references) on disk so that they may be retrieved at some later
  50.           time?
  51.   [5-5]   Given the name of a class, how can I get the names of its slots?
  52.   [5-6]   Free CLOS software.
  53.  
  54. Search for \[#\] to get to question number # quickly.
  55.  
  56. In general, questions about object oriented programming in Lisp,
  57. especially questions about using CLOS or compiling PCL, should be
  58. directed to the newsgroup comp.lang.clos.
  59.  
  60. ----------------------------------------------------------------
  61. Subject: [5-0]  What is CLOS (PCL) and where can I get it?
  62.                 How do you pronounce CLOS?
  63.  
  64. CLOS (Common Lisp Object System) is the object-oriented programming
  65. standard for Common Lisp. It is the successor to Symbolics FLAVORS and
  66. Xerox LOOPS (Lisp Object Oriented Programming System). The acronym
  67. CLOS is pronouned either as "See-Loss" or "Closs", depending on taste.
  68. PCL (Portable Common Loops) is a portable CLOS implementation, and is
  69. available by anonymous ftp from parcftp.xerox.com (13.1.64.94) in the
  70. /pub/pcl/ directory. Also in the same directory are sources for CLX R5
  71. and an inspecter.
  72.  
  73. Most Common Lisp implementations now include their own CLOS
  74. implementations. Common Lisp implementations with native CLOS include:
  75. MCL, {A}KCL, Allegro CL (including Allegro CL\PC), Ibuki, Lucid,
  76. Medley, Symbolics Genera, CLOE, and Harlequin Lispworks. CMU CL uses a
  77. customized version of PCL as their CLOS. However, not all native CLOS
  78. implementations have as detailed a meta-object protocol as PCL. For
  79. example, MCL 2.0 users sometimes use the july-1d version of PCL
  80. instead of the native CLOS for precisely this reason.
  81.  
  82. The sources for the CLOS Metaobject Protocol specification are
  83. also available from parcftp as /pub/pcl/mop/spec.tar.Z. See also the book
  84. ``The Art of the Metaobject Protocol'' below. The Closette files
  85. related to this book are available from parcftp as /pub/pcl/mop/closette.lisp.
  86.  
  87. The CLOS code repository is available by anonymous ftp to
  88. nervous.cis.ohio-state.edu [128.146.61.200] in the directory
  89. pub/lispusers/clos/. If you've got code you'd like to add to the
  90. repository, send mail to Arun Welch, commonloops-request@cis.ohio-state.edu.
  91.  
  92. ----------------------------------------------------------------
  93. Subject: [5-1] What documentation is available about object-oriented
  94.                programming in Lisp? 
  95.  
  96. Books about object-oriented programming in Lisp include:
  97.  
  98.    1. dpANS CL describes the entire Common Lisp language, which includes the
  99.       CLOS standard.  Informally, CLtL2 can also be used to learn about CLOS, 
  100.       but please remember that CLtL2 is not an official X3J13 committee
  101.       document. (The presentation of CLtL2 differs from that of the draft
  102.       proposed standard, and some matters of fact have changed in the proposed
  103.       standard since the publication of CLtL2.)
  104.  
  105.    2. Sonya E. Keene
  106.       "Object-Oriented Programming in Common Lisp: 
  107.        A Programmer's Guide to CLOS"
  108.       Addison-Wesley (Reading, MA), 1989. 266 pages. ISBN 0-201-17589-4.
  109.            Tutorial introduction to CLOS with many examples and
  110.            a lot of good advice for designing large programs using CLOS.
  111.  
  112.    3. Jo A. Lawless and Molly M. Miller.
  113.       "Understanding CLOS: the Common Lisp Object System"
  114.       Digital Press, 1991. 192 pages.
  115.  
  116.    4. Gregor Kiczales, Jim des Rivieres, and Daniel G. Bobrow.
  117.       "The Art of the Metaobject Protocol"
  118.       MIT Press, 1991. 335 pages. ISBN 0-262-61074-4
  119.            The first part of the book presents a model CLOS implementation,
  120.            introduces the basic principles of metaobject protocols, and 
  121.            works through the key elements of the CLOS Metaobject Protocol.
  122.            The second half is the detailed specification of the CLOS
  123.            Metaobject Protocol. A simple working interpreter suitable
  124.            for experimentation is contained in an appendix.
  125.  
  126.    5. Robert R. Kessler and Amy R. Petajan.
  127.       "LISP, Objects, and Symbolic Programming"
  128.       Scott, Foresman and Company (Glenview, IL), 1988. 644 pages.
  129.            Includes a small Lisp compiler.
  130.  
  131.    6. A short introduction to CLOS written by Jeff Dalton of the
  132.       University of Edinburgh <J.Dalton@ed.ac.uk> is available by
  133.       anonymous ftp from  
  134.          aiai.ed.ac.uk:/lisp/random [192.41.104.6]
  135.       as the file clos-guide.
  136.  
  137. ----------------------------------------------------------------
  138. Subject: [5-2] How can I write a function that can access defstruct slots 
  139.                by name?  I would like to write something like 
  140.                (STRUCTURE-SLOT <object> '<slot-name>).
  141.  
  142. There is currently no portable, built-in way to access structure slots
  143. given only the name.  If your Common Lisp includes an implementation
  144. of CLOS that supports the meta-object protocol specified in the
  145. original X3J13 draft spec (document X3J13/88-003), then it probably will
  146. allow (SLOT-VALUE <object> '<slot-name>); however, not all
  147. implementations of CLOS currently provide this.  Lacking this, some
  148. implementations may provide implementation-dependent functions that
  149. allow access to structure slots by name; note that this may cause
  150. saved images to be larger, as some implementations normally open-code
  151. structure accessors and discard slot name information.
  152.  
  153. While it is not possible to write a fully general STRUCTURE-SLOT function,
  154. it is not very difficult to write version that handles specific structure
  155. types.  For instance, after defining:
  156.  
  157.    (defstruct spaceship name captain position velocity)
  158.  
  159. one may then define:
  160.  
  161.    (defun spaceship-slot (spaceship slot-name)
  162.      (ecase slot-name
  163.        (name (spaceship-name spaceship))
  164.        (captain (spaceship-captain spaceship))
  165.        (position (spaceship-position spaceship))
  166.        (velocity (spaceship-velocity spaceship))))
  167.  
  168. or using CLOS (generic functions):
  169.  
  170. (defgeneric spaceship-slot (spaceship slot-name)
  171.   (:method ((x spaceship) (slot (eql :name)))
  172.     (spaceship-name x))
  173.   (:method ((x spaceship) (slot (eql :captain)))
  174.     (spaceship-captain x))
  175.   (:method ((x spaceship) (slot (eql :position)))
  176.     (spaceship-position x))
  177.   (:method ((x spaceship) (slot (eql :velocity)))
  178.     (spaceship-velocity x)))
  179.  
  180. Another popular way to define this is:
  181.  
  182.    (defun spaceship-slot (spaceship slot-name)
  183.      (funcall (symbol-function
  184.                 (find-symbol (format nil "SPACESHIP-~A" slot-name)
  185.                              #.(package-name *package*)))
  186.               spaceship))
  187.  
  188. I personally recommend the first version.  It is likely to be much faster
  189. and more memory efficient than the second version.  It's also easy to get
  190. the second one wrong; many people forget to specify the package argument to
  191. FIND-SYMBOL, which can cause incorrect results when the package at run time
  192. is different from the one at compile time.  Even my version assumes that
  193. SPACESHIP-SLOT is being defined in a file that is in the same package as
  194. the one containing the structure definition; if this isn't the case,
  195. #.(PACKAGE-NAME *PACKAGE*) should be replaced by a string naming the
  196. correct package.
  197.  
  198. Another workaround is to define a MY-DEFSTRUCT macro that parses the
  199. defstruct arguments and expands into a call to DEFSTRUCT along with a
  200. definition of the runtime slot-accessor function.
  201.  
  202. Some non-portable techniques include the use of SYSTEM:STRUCTURE-REF
  203. in Lucid (LCL:STRUCTURE-REF in earlier versions of Lucid) and 
  204. EXCL:STRUCTURE-REF in Allegro. 
  205. ----------------------------------------------------------------
  206. Subject: [5-3] How can I list all the CLOS instances in a class?
  207.  
  208. There is no built-in way to enumerate the instances of a class.  If you are
  209. only interested in listing the instances of classes that you have defined,
  210. it is not very difficult to implement it as part of your class definition.
  211. Add a shared slot, e.g. ALL-INSTANCES, with an initial value of NIL, to the
  212. class definition.  Then write an after-method on INITIALIZE-INSTANCE for
  213. this class, which pushes the instance being initialized onto ALL-INSTANCES.
  214. Note that this must be done separately for each class that wants to maintain
  215. such a list; it can't be encapsulated in a mixin class, because all its
  216. dependent classes would share the same ALL-INSTANCES slot.  A compromise
  217. would be to use a mixin to define the INITIALIZE-INSTANCE after-method (and
  218. any other general-purpose methods that use the slot), but not the shared
  219. slot; it would be up to the descendant classes to define the slot at the
  220. level of the class hierarchy that is appropriate. You could also try
  221. defining the classes that need instance-recording as instances of a
  222. metaclass that holds the instance registry on the class object. The
  223. recording behavior could then be built-in to an after method on
  224. initialize-instance for the root class of the metaclass, or even
  225. allocate-instance. To allow for garbage collection of old instances,
  226. you will also need to define a generic function to remove the recorded
  227. instances from the list of instances.
  228. ----------------------------------------------------------------
  229. Subject: [5-4]  How can I store data and CLOS instances (with possibly 
  230.                 circular references) on disk so that they may be
  231.                 retrieved at some later time?
  232.  
  233. There are two main techniques of doing this kind of persistent object
  234. storage. The first involves using #. to compile the data into a file.
  235. The second produces an ASCII representation which, when evaluated,
  236. will reproduce an equivalent set of data.
  237.  
  238. If the data you wish to save is stored in the variable *hash-table*,
  239. create a file containing just the lines
  240.         (in-package "YOUR-PACKAGE")
  241.         (setq *hash-table* '#.*hash-table*)
  242. and compile it. The #. macro performs read-time evaluation of the
  243. expression following the dot, and so this compiles the data into the
  244. file. You may then load the file to restore the data. However, the
  245. resulting binary file is not portable between Lisp implementations,
  246. and sometimes not even for the same Lisp on different platforms. Also,
  247. some Lisps will treat the data as constant, and place it on pages in
  248. memory that are marked read-only (after it is loaded). If one tries to
  249. later modify the data, these Lisps will signal an error. Lucid CL only
  250. puts such constants in a read-only area when they appear inside
  251. functions, so this should be safe. Allegro CL doesn't seem to complain
  252. about modification if the data is a cons. DEC's VAXLisp, however, has
  253. problems with #. circular structures in .fas files. MCL seems to work
  254. well with using #. to save data (and even functions) to a file.
  255.  
  256. The other technique is to produce an ASCII representation of the Lisp
  257. objects which may then be saved to a file. To reproduce the data, one
  258. can load (or compile and load) the file. This technique is portable
  259. between different Lisps and platforms. Unfortunately, the resulting
  260. data is not necessarily EQ to the original. Kerry Koitzsch's
  261. save-object.lisp package is included in the Lisp Utilities Repository,
  262. ftp.cs.cmu.edu:/afs/cs.cmu.edu/user/mkant/Public/Lisp-Utilities/.
  263. (Note: You must cd to this directory in one atomic operation, as some
  264. of the superior directories on the path are protected from access by
  265. an anonymous ftp.) The Lisp Utilities Repository is described in
  266. detail in the answer to question [6-1].
  267.  
  268. See also the discussion of MAKE-LOAD-FORM and MAKE-LOAD-FORM-SAVING-SLOTS 
  269. in CLtL2.
  270.  
  271. WOOD (William's Object Oriented Database) is a simple persistent object
  272. store for MCL 2.0, written by Bill St. Clair <bill@cambridge.apple.com>.
  273. Its goal is to provide a way to save/restore Lisp objects to/from disk.
  274. It is available by anonymous ftp from the MCL repository on
  275. cambridge.apple.com:pub/MCL2/CONTRIB/. Send bug reports to
  276. bug-wood@cambridge.apple.com. To be added to the mailing list, send mail
  277. to info-wood-request@cambridge.apple.com.
  278.  
  279. ----------------------------------------------------------------
  280. Subject: [5-5] Given the name of a class, how can I get the names
  281.                of its slots?     
  282.  
  283. (defun class-slot-names (class-name)
  284.   "Given a CLASS-NAME, returns a list of the slots in the class."
  285.   (mapcar #'clos:slot-definition-name
  286.           (clos:class-slots (find-class class-name))))
  287.  
  288. (defmethod class-slot-names ((instance standard-object))
  289.   "Given an INSTANCE, returns a list of the slots in the instance's class."
  290.   (mapcar #'clos:slot-definition-name
  291.           (clos:class-slots (class-of instance))))
  292.  
  293. You can use CLASS-DIRECT-SLOTS instead of CLASS-SLOTS if you don't
  294. want inherited slots. Note that these functions are from the
  295. meta-object protocol specified in the original X3J13 draft spec
  296. (document X3J13/88-003), and may not be supported by all Lisps.
  297.  
  298. ----------------------------------------------------------------
  299. Subject: [5-6] Free CLOS software.
  300.  
  301. Software Repositories:
  302.  
  303.    The CLOS code repository is available by anonymous ftp to
  304.    nervous.cis.ohio-state.edu [128.146.61.200] in the directory
  305.    pub/lispusers/clos/. If you've got code you'd like to add to the
  306.    repository, send mail to Arun Welch, commonloops-request@cis.ohio-state.edu.
  307.    The CLOS code repository includes dag.lisp.Z and 3DGeometry.lisp.
  308.  
  309. CORBA:
  310.  
  311.    The CORBA specification's Dynamic Invocation Interfaces (DII) are a
  312.    collection of interfaces for writing extensible, distributed object
  313.    applications.  NEC Systems Laboratory Inc. has contributed both C and
  314.    CLOS implementations of these specification to the OMG.  The CORBA
  315.    specification as well as the DII implementation can be retrieved via
  316.    anonymous ftp from omg.org:pub/ [192.67.184.64] as the files
  317.    NEC_DII/93-1-2.tar.Z and corba.ps.Z. There are three dependencies in
  318.    the contributed DII implementations.  First, the CLOS images require
  319.    an Allegro CL license due to its use of the Lisp foreign function
  320.    interface.  Second, the C executables require Sun SparcStations, but
  321.    they can be re-compiled and re-linked for other architectures.  Third,
  322.    the implementation of the `Invoke' DII interface is considered
  323.    proprietary.  For further information, write to Don Vines, NEC Systems
  324.    Laboratory, Inc., C&C Software Technology Center (CSTC), 1901 Gateway
  325.    Drive, Irving, Texas 75038, call 214-518-3486, fax 214-518-3552, or
  326.    send email to dvines@syl.dl.nec.com.
  327.  
  328. ----------------------------------------------------------------
  329. ;;; *EOF*
  330.  
  331.